Field of the Invention
The present invention relates to programmable integrated circuit technology, and specifically to system on a chip (SoC) technology. More particularly, the present invention relates to providing 100% visibility, and exercising 100% controllability on single-clock domain, synchronous SoC-FPGA design, by way of creating a spatial snapshot, obtained from dynamically configurable trigger without altering the original design being debugged.
Description of Related Art
It is desirable to provide complete visibility and controllability of a single-clock domain, synchronous system on a chip field programmable gate array (SoC-FPGA) design, by way of creating a spatial snapshot, obtained from a dynamically configurable trigger without altering an original design being debugged. A spatial snapshot of the SoC-FPGA represents the state of all of the memory elements, such as all of the flip-flops and all of the memory cells (SRAM, etc.) utilized in the design.
There is no known method to create a snapshot of the entire FPGA design using a dynamically configurable trigger and to then exercise execution control to influence the design without altering the structure of the design.
The SmartFusion2 (SF2) SoC-FPGA manufactured and marketed by the SoC Products Group of Microsemi Corporation is unique in its architecture as it enables the reading and writing of all of its memory elements, e.g., flip-flops, SRAM memory cells, etc.
The SmartDebug application running on a PC connected to an SF2 integrated circuit via JTAG or SPI interfaces allows the user to dynamically configure the trigger and retrieve the state of all of the memory elements upon encountering the trigger. It also provides options for execution control. The availability of both JTAG and SPI interfaces enables debugging with multiple tools on different interfaces simultaneously.
Referring now to FIG. 1, a flow diagram depicts a prior art chronological debug procedure indicated generally at reference numeral 10. At reference numeral 12, a circuit design is input to the system. The circuit design may be in the form of either schematic capture of the digital logic to be synthesized or RTL, which is synthesizable HDL (hardware description language) code typically written in Verilog/VHDL, etc. Optional design constraints 14, such as synthesis directives, may be attached to specific modules in the design input. Examples of synthesis directives are timing constraints (clock frequency, false and multi-cycle paths, etc.), location constraints, one-hot encoding of FSMs, fan-out limits, net/module preservation, logic replication, etc.
At reference numeral 16, the circuit design input 12 and constraints 14 are provided to synthesis software (a compiler that translates RTL (register transfer level) into logic gates), which produces an EDIF netlist at reference numeral 18 along with constraints 20. EDIF (electronic design interchange format) is a vendor-neutral format in which to store electronic netlists and schematics. Constraints 20 are FPGA vendor-specific design constraints, such as map, place, and route directives attached to specific modules in design input. Examples of FPGA vendor-specific design constraints are timing constraints (clock frequency, false and multi-cycle paths, etc.), location constraints, area (floor-planning) constraints, and vendor-specific attributes, etc.
The EDIF netlist 18 and constraints 20 are provided to map, place, and route software 22 to produce a proprietary netlist 24. Map, place, and route software is a vendor-specific back-end tool that translates EDIF netlist into a vendor-specific proprietary netlist that contains the entire design implementation for the target FPGA device. The proprietary netlist 24 is provided to program file generator software 26 (a vendor-specific back-end tool that translates the proprietary netlist into a proprietary bitstream file) to produce a proprietary programming file 28 (a vendor-specific proprietary bitstream file that contains the design). At reference numeral 30, an FPGA programming tool is used to program the design into an FPGA integrated circuit 32 on a circuit board. The FPGA programming tool is a vendor-specific programming application that uses a proprietary programming file to configure, via proprietary cable hardware, the target hardware device (FPGA).
For a given design, the debug process begins with the processes described with respect to reference numerals 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, and 32. After the integrated circuit has been programmed, an external stimulus, at reference numeral 34, can be applied to the system including integrated circuit 32. The external stimulus 34 is a logical vector sequence (of 1s and 0s) applied at the input pins of the FPGA device, i.e., the design under test (DUT). Various devices either on the board or outside of the board generate the external stimulus.
At reference numeral 36, the external system response to the stimulus is captured and presented to oscilloscope or logic analyzer 38. The external system response 36 is a logical vector sequence (of 1s and 0s) observed at the output pins of the DUT FPGA device. Various devices either on the board or outside of the board sample and/or process the external response. The logic analyzer or digital oscilloscope instrument captures, stores, and displays the external response, typically in the shape of a waveform on the monitor. It is at this step that the user determines from the response whether there is a bug in the design and whether further steps to debug as described below are required.
The response to the stimulus 34 internal to the integrated circuit is captured at reference numeral 40 and presented to an analyzer tool 42. The logical vector sequence (of 1s and 0s) is captured by the instrumented integrated logic analyzer embedded in the design. The internal response 34 can only be monitored for the signals instrumented by an instrumentor tool 44 or 46. The analyzer tool 42 is an application running on a PC that allows a user to select from the pre-determined trigger (instrumented by the intstrumentor tool), arms the integrated logic analyzer and waits to download internal response stored in the instrumented integrated logic analyzer, and displays the response typically in the shape of a waveform on the monitor. The instrumentor tools 44, 46 are applications running on a PC that instruments user-specified observation and trigger signals via an integrated logic analyzer, which gets merged with the design being debugged in the format of a synthesized netlist. User formulates hypothesis based on the observability provided by the analyzer tool 42 and invokes either the instrumentor tool 44 or 46 to alter the observability signals in the design, and adds this new observability to the design at map, place, and route software 22 or synthesis software 16, respectively.
There are problems with using prior art chronological debug processes, such as the one illustrated in FIG. 1. The prior art chronological debug process is both iterative and intrusive in nature. The faults in the design are observable in processes 34, 32, 40, 42 or 34, 32, 36, 38. Then the debug procedure cycles through processes 40, 42, 44, 22, 26, 30, 34, 40 or 40, 42, 46, 16, 22, 26, 30, 34, 40 and only ends when the bug has been discovered. This can take many loops through these processes.
As may be seen from FIG. 1, current FPGA debug technology heavily relies on iterative debug cycles, which makes it time and computation intensive. As in any debug flow, the designer would formulate a hypothesis based on the symptoms observed and decide to which part of the design is to be targeted. The designer almost always has to go through multiple hypothesis formulations, shifting the instrumentation from one logic block to another, before closing in on the root cause, i.e., the problematic area in the design. As the size of FPGA devices continues to increase and the SoC functionality continues to grow, gaining visibility and controllability into the device becomes exponentially challenging; thus drastically increasing the number of iterations required in the debug cycle. This, in turn, increases the cost of the manual debug process, the cost of re-instrumentation, and the risk associated with re-instrumentation, such as design alteration.
In order to gain visibility into multiple spatially distributed areas of the design under test (DUT), multiple instances of debug logic are required to gain visibility with often limited and precious FPGA resources, which are not always available in a densely utilized design. As a result of this shortcoming, the current FPGA technology based on iterative instrumentation and debug cannot guarantee debug success.
The success of the iterative instrument-debug cycles is a function of the availability of FPGA resources, the probability of FPGA timing closure with added instrumentation, and repeatability of the bug (i.e., fixed stimuli, fixed device under test (DUT)). Re-instrumentation is extremely undesirable because it is a manual process and, thus, susceptible to user error, it depends on the efficiencies of the tool flow (tool flow runs into several minutes for very small designs to several hours for large designs) and there is no guarantee that any given tool flow iteration will succeed in either fitting (utilization <100%) or timing closure (meets all timing constraints). This uncertainty limits the designers' visibility into their design. Even though iterative instrumentation is a common debug practice, in view of the reasons set forth above, excessive iteration (>3 attempts) is counterproductive.
Intrusive debugging processes have also been used for SoC FPGA devices. Instrumentation of the debug logic can be done using two common methods in the tool-flow, at RTL level and at post-synthesis. Instrumentation at RTL level effectively adds additional debug RTL code to the original RTL code base, while instrumentation at the post-synthesis level adds an additional netlist to the original netlist. Both methods consume additional resources (LUTs, FFs, RAMs, buffers, routing lines, etc.) and both methods alter the final placed and route netlist, which often looks very different from the original netlist.
There are several negative, unintended consequences of such intrusive debugging on the debug process. First, debug visibility is marred due to changes in netnames and FF names, and disappearance of nets and FFs during the synthesis and map optimization process. Timing changes are introduced due to placement and routing changes, fan-out on the clock(s) that are used for instrumented debug logic. In addition, the ability to reproduce a bug is crippled due to alteration of the original DUT netlist and such an alteration may have inadvertently fixed the problem (if there was a timing-related issue) or may have simply masked the problem (loss of visibility). Both outcomes, if they occur, are very difficult to identify and the process of debug becomes very challenging and time-consuming.
FPGA vendors claim to have less intrusive debugging techniques like post-layout probing using incremental place and route, but this is still intrusive in the sense that signals to be monitored have to be routed to FPGA inputs and outputs (I/Os). In most customer designs, the number of FPGA I/Os for debugging purposes are very limited and boards are often not designed with this style of FPGA debug approach. In some instances the user is prompted to cannibalize the user I/Os already in use, thereby altering the DUT. Furthermore, the incremental place and route will still add fan-out to the node being monitored, and there is no guarantee that the placer or router will succeed.
Conventional FPGA and SoC devices have limitations. While the FPGA is a great platform for emulation and SoC is great for reducing board size, the device architecture does not allow or has very limited provision for observability, controllability, and execution control.
When a certain design fails on the device, it is desirable to gain spatial and temporal visualization into the device. However, in conventional devices, this requires instrumentation in advance, i.e., the designer has to add in design specific observation points. Adding observation points in the design costs device resources and may not be possible in an over-utilized or congested design. This approach is, therefore, extremely limited in scope and fails to provide adequate, if not 100%, visibility into the design. Without good observability, a designer can analyze the execution of a circuit only by repeated execution to characterize its behavior.
Limited controllability has been an issue in bug fixing in SoC FPGA devices. Some classes of bugs are difficult to reproduce because of ineffective or extremely long (time-consuming) stimuli vectors at the device I/Os. It is often desirable to accelerate or manipulate the state transitions of certain finite state machines (FSMs) by employing localized over-ride logic (similar to force in Verilog simulations). Another demand for a controllability feature would be to induce errors into the stimulus vectors for negative testing that are otherwise difficult to achieve by applying stimuli at the device I/Os.
Once again, adding controllability is impossible in the device without instrumentation in advance. As in the case of adding observation points, adding control points consumes device resources, and it is extremely limited in scope and fails to provide adequate, if not 100%, controllability of the design.
Another aspect of debugging is the ability to control the clock in the DUT and manipulate the stimulus vector applied to the DUT. There is very limited ability within existing commercial FPGA debugging tools to control the clock in the DUT and manipulate the stimulus vector applied to the DUT. It would be useful to have the capability to freeze the DUT at interesting points in time, obtain a spatial view of all of the memory elements in the design, manipulate the stimulus vector and/or the internal states of the DUT for mimicking error injection or for overriding real-life stimuli, and then advance the clock by one or more clock cycles to capture the response. Execution control is a very common concept in firmware debugging and is applied frequently using in-circuit emulators (ICE) or debuggers. But when it comes to hardware debugging, or hardware-software co-verification, the execution control in an FPGA is limited by the architecture of the FPGA itself.